Snowflakeの新UI「Snowsight」でクエリ履歴を可視化してみた

「カスタマーストーリー」を支えるツール特集

#Snowflake

#ビジネス・アナリティクス

#ビッグデータ

#Snowsight

エノカワ

2021.07.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは！エノカワです。

Snowflakeの新しいUI「Snowsight」がプレビュー機能で公開されています。

Snowsightではグラフとダッシュボードを使用して、データの可視化をすることができますが、
今回はデータそのものの可視化ではなく、データのクエリ履歴の可視化を試してみました。

Snowsightの簡単な利用方法などについてはこちらの記事にも記載しています。

前提条件

前回の記事ではデータのロード履歴の可視化を試しました。
こちらの記事で使用したサンプルデータベースとウェアハウスを今回も使用します。

サンプルデータベース:SNOWFLAKE_SAMPLE_DATA
ウェアハウス: DEMO_WH

クエリ実行

サンプルデータベースSNOWFLAKE_SAMPLE_DATAのテーブルに対してクエリを実行し、
その履歴を可視化してみましょう。

Snowsightのワークシート上で、以下のクエリを実行していきます。

コンテキスト設定

検証で使用するロールとウェアハウスを指定します。

use role SYSADMIN;
use warehouse DEMO_WH;

パラメータ設定

検証で使用するパラメータを指定します。

USE_CACHED_RESULT

キャッシュされたクエリ結果を再利用するかどうかをブール値で指定するパラメータです。

今回のクエリではクエリ結果を再利用したくないのでFALSEを指定します。

alter session set USE_CACHED_RESULT = FALSE;

QUERY_TAG

セッション内で実行されるクエリのタグ付けに使用できるオプションの文字列です。

今回は可視化対象のクエリを識別するために使用します。

ラインアイテム数をクエリするのでラインアイテム数を指定します。

alter session set QUERY_TAG = 'ラインアイテム数';

クエリ

サンプルデータのドキュメントで紹介されているクエリを実行します。

クエリは、合計価格、割引合計価格、割引合計価格と税金、平均数量、平均合計価格、および平均割引の合計をリストします。これらの集計は、RETURNFLAG と LINESTATUS でグループ化され、RETURNFLAG と LINESTATUS の昇順でリストされます。各グループのラインアイテム数の件数が含まれます。

サンプルデータ：TPC-H — Snowflake Documentation

use database snowflake_sample_data;
use schema snowflake_sample_data.tpch_sf1;

select
       l_returnflag,
       l_linestatus,
       sum(l_quantity) as sum_qty,
       sum(l_extendedprice) as sum_base_price,
       sum(l_extendedprice * (1-l_discount)) as sum_disc_price,
       sum(l_extendedprice * (1-l_discount) * (1+l_tax)) as sum_charge,
       avg(l_quantity) as avg_qty,
       avg(l_extendedprice) as avg_price,
       avg(l_discount) as avg_disc,
       count(*) as count_order
 from
       lineitem
 where
       l_shipdate <= dateadd(day, -90, to_date('1998-12-01'))
 group by
       l_returnflag,
       l_linestatus
 order by
       l_returnflag,
       l_linestatus;

クエリを実行すると各グループの集計結果が返ってきます。

サンプルデータには、さまざまなデータセットサイズが付属しています。
データは、SNOWFLAKE_SAMPLE_DATA共有データベースの次のスキーマで提供されます。

TPCH_SF1:基本行サイズで構成されます（数百万の要素）。
TPCH_SF10:基本行サイズx 10で構成されます。
TPCH_SF100:基本行サイズx 100（数億の要素）で構成されます。

TPCH_SF1は先ほどクエリを実行しましたので、
残り２つのスキーマに対しても同じクエリを実行してみましょう。

先ほどのクエリの1行目を以下に置き換えて実行します。

use schema snowflake_sample_data.tpch_sf10;

use schema snowflake_sample_data.tpch_sf100;

クエリの実行が完了したので、パラメータを元に戻します。

alter session unset QUERY_TAG;
alter session set USE_CACHED_RESULT = TRUE;

クエリ履歴の可視化

それではサンプルデータのクエリ履歴を可視化してみましょう。

QUERY_HISTORYテーブル関数

クエリ履歴を取得するためにQUERY_HISTORYテーブル関数を使用します。
取得できる項目については、ドキュメントを参照ください。

QUERY_HISTORY：指定された時間範囲内のクエリを返します。
QUERY_HISTORY_BY_SESSION：指定されたセッションと時間範囲内のクエリを返します。
QUERY_HISTORY_BY_USER：指定された時間範囲内で指定されたユーザーによって送信されたクエリを返します。
QUERY_HISTORY_BY_WAREHOUSE：指定された時間範囲内で指定されたウェアハウスによって実行されたクエリを返します。

QUERY_HISTORY_BY_SESSIONテーブル関数を使用して、クエリ履歴を取得してみましょう。

以下のクエリを実行すると、現在のセッションで実行された最後の100クエリまで取得します。

select * from table(information_schema.query_history_by_session())
    order by START_TIME desc;

13件のクエリ履歴が取得できました。

今回の検証では以下の項目を使用します。

QUERY_ID：ステートメントの一意のID。
QUERY_TEXT：SQL ステートメントのテキスト。
QUERY_TYPE：DML、クエリなど。クエリが現在実行中の場合、またはクエリが失敗した場合、クエリタイプは UNKNOWNになります。
QUERY_TAG：QUERY_TAG セッションパラメーターを介してこのステートメントに設定されたクエリタグ。
TOTAL_ELAPSED_TIME：経過時間（ミリ秒）
COMPILATION_TIME：コンパイル時間（ミリ秒）
EXECUTION_TIME：実行時間（ミリ秒）

QUERY_TYPEに注目してみましょう。

先ほど実行したクエリの結果には、QUERY_HISTORY_BY_SESSIONテーブル関数のクエリも含まれていました。
実行中のため、QUERY_TYPEがUNKNOWNになっています。

クエリIDごとの経過時間

実行が完了したクエリについて、QUERY_IDごとの経過時間を可視化していましょう。

実行が完了したクエリに限定するため、QUERY_TYPEにUNKNOWN以外を指定してクエリを実行します。

select * from table(information_schema.query_history_by_session())
    where QUERY_TYPE <> 'UNKNOWN'
    order by START_TIME desc;

実行が完了したクエリ履歴が取得できました。
Chartタブをクリックして、表示を切り替えてみましょう。

QUERY_IDごとの経過時間が横棒グラフで表示されました！

グラフの設定は以下のようになっています。

クエリテキストごとの経過時間

QUERY_IDだと何のクエリか分からないので、SQL ステートメント表示に変更してみましょう。
Y-Axis（Y軸）をQUERY_TEXTに変更します。

QUERY_TEXTごとの経過時間に変わりました！
SQL ステートメントごとに集計されており、経過時間の合計が表示されています。

クエリタイプごとの平均経過時間

今度はY-Axis（Y軸）をQUERY_TYPEに変更してみましょう。

SELECTなどクエリタイプごとに集計されますので、Aggregationも変更しておきましょう。
Use asをSum（合計）からAverage（平均）に変更します。

QUERY_TYPEごとの平均経過時間に変わりました！

スキーマごとの経過時間

クエリ実行の際、3つのスキーマを切り替えて実行しました。

各スキーマの経過時間を可視化して比較してみましょう。

まずは取得するクエリ履歴をSELECTのみに限定します。

select * from table(information_schema.query_history_by_session())
    where QUERY_TYPE = 'SELECT'
    order by START_TIME desc;

SELECTのクエリ履歴が取得できました。

QUERY_TEXTを見てみると、QUERY_HISTORYテーブル関数の履歴も含まれているのが分かります。

ここでQUERY_TAGの出番です。

各スキーマに対するクエリのQUERY_TAGはラインアイテム数になっていますね。

取得するクエリ履歴をQUERY_TAGがラインアイテム数のみに限定します。

select * from table(information_schema.query_history_by_session())
    where QUERY_TYPE = 'SELECT'
      and QUERY_TAG = 'ラインアイテム数'
    order by START_TIME desc;